4.1.3 -
Présentation des composants
E-Sentry :
4.1.3.A - Le serveur de sécurité
E-Sentry (installé sur Eridan) :
C’est le composant central de e-Sentry. Il assure les services
d’authentification, d’accréditation et d’administration
de sécurité.
- Il prend en charge l’authentification des utilisateurs accédant
par leur browser (identifiant/ mot de passe ou certificats) ;
- Il communique l’accréditation des utilisateurs aux
WebAgents ;
- Il dispose des outils interactifs et batch d’administration de sa base
de sécurité ;
- Il assure la synchronisation automatique des données de
sécurité avec les serveurs de sécurité
distants ;
- Fonctionnant en miroirs, l’indisponibilité d’un
serveur de sécurité est compensée par un de ses miroirs
sans dégradation de service (modèle multi-maîtres de
distribution des données de sécurité).
Le
schéma suivant illustre le fonctionnement du serveur de
sécurité :
Figure 124 : Schéma de
fonctionnement du serveur de sécurité E-Sentry
4.1.3.B - Le WebAgent (installés sur les
serveurs Colombe et Fleche) :
C’est le composant local de sécurité
e-Sentry.
- Il est normalement intégré au serveur HTTP de
l’application (module exit) ;
- Il assure le contrôle d’accès aux applications Web en
filtrant les requêtes (URL) vers les applications ;
- Il est placé en amont de l’application et agit sur le protocole
HTTP ;
- Il est capable d’enrichir les requêtes (URL) entrantes par des
paramètres reçus dans les accréditations (paramètres
de sécurité, attributs utilisateur, profils d’accès,
...) ;
- Il met en œuvre un ‘cache’ local pour mémoriser les
accréditations déjà reçues ;
- Il est capable de re-router l’utilisateur vers le serveur
d’authentification si nécessaire ;
- Il est piloté par un fichier de configuration local et par les
serveurs de sécurité e-Sentry avec qui il dialogue
(réception des accréditations) ;
- Cette configuration locale permet de choisir les serveurs
d’authentification et d’accréditation ;
- Le WebAgent permet un back up de l’authentification via le navigateur
de l’utilisateur et assure un back up automatique direct des serveurs
d’accréditation ;
- Il peut être associé, via des fonctions EXIT, à des
serveurs HTTP de technologie Apache, Netscape, IIS4 et IIS5, Lotus
Domino.
Le schéma suivant illustre le fonctionnement du
webagent :
Figure 125 : Schéma de
fonctionnement du WebAgent
4.1.3.C - Le FrontServer (installé sur
Fleche) :
Le Front Server est une extension du WebAgent. Il permet d’installer
le WebAgent sur un serveur HTTP distinct du serveur HTTP de l’application.
Le FrontServer fonctionne en mode ‘Reverse Proxy’, masquant le
chemin d’accès direct au serveur d’application.
Cette
possibilité permet de répondre aux besoins suivants :
- Le serveur d’application est dans l’Intranet que l’on
souhaite isoler de l’accès Internet. En plaçant le Front
Server dans une ‘Zone démilitarisée’, les adresses
effectives des serveurs internes sont cachées de
l’Internet ;
- Le serveur HTTP de l’application ne permet pas l’adjonction
d’un WebAgent ;
- On souhaite établir une connexion sécurisée SSL entre
les utilisateurs et l’application mais l’application ne supporte pas
ce protocole. Ceci étant, le FrontServeur est capable d’assurer une
liaison SSL sur le tronçon FrontServer –
applicationWeb.
Le Front Serveur permet:
- Le masquage des serveurs applicatifs réels ;
- Les fonctions de filtrage, reroutage et ajout de paramètres
grâce au WebAgent intègré ;
- La Frontalisation de une ou plusieurs applications situées sur des
serveurs physiques différents ;
- La simplification des protections des sous-réseaux par les
FireWall ;
- Le déploiement d’autant de FrontServers que
nécessaire.
Selon le cas, il peut être
implanté :
- Sur un serveur et/ou un réseau distinct lorsqu’il s’agit
d’isoler le serveur d’application ;
- Sur le serveur applicatif lui-même lorsque l’objectif est de
compléter le serveur HTTP local.
Les front Serveurs
sont basé sur la technologie HTTP Apache. L’exploitation d’un
Front Server se réduit à la configuration du serveur HTTP et du
fichier de configuration du WebAgent associé. Par ailleurs il ne contient
pas de données applicatives évolutives nécessitant des
sauvegardes régulières. L’important est sa
disponibilité (il frontalise les applications).
Le schéma
suivant illustre le fonctionnement d’un frontserver :
Figure 126 : Schéma de
fonctionnement du frontserver
